The present invention is generally directed to USB device redirection in a virtual desktop infrastructure (VDI) environment. USB device redirection generally refers to making a USB device that is connected to a client accessible within a virtual desktop as if the USB device had been physically connected to the virtual desktop. In other words, when USB device redirection is implemented, a user can connect a USB device to his or her client terminal and the USB device will function as if it had been connected to the server.
FIGS. 1-3 and the following description will provide a general overview of how USB device redirection can be implemented in accordance with some embodiments of the present invention. In FIG. 1, a computing system 100 is depicted as including a number of client terminals 102a-102n (referenced generally herein as client(s) 102) in communication with a server 104 via a network 106. Server 104 can be configured to support a remote session (e.g., a remote desktop session) wherein a user at a client 102 can remotely access applications and data at the server 104 from the client 102. Such a connection may be established using any of several well-known techniques such as the Remote Desktop Protocol (RDP) and the Citrix® Independent Computing Architecture (ICA).
Client terminal 102 may represent a computer, a mobile phone (e.g., smart phone), a laptop computer, a thin client terminal, a personal digital assistant (PDA), a portable computing terminal, or a suitable terminal or device with a processor. Server 104 may represent a computer, a laptop computer, a computing terminal, a virtual machine (e.g., VMware® Virtual Machine), a desktop session (e.g., Microsoft Terminal Server), a published application (e.g., Microsoft Terminal Server) or a suitable terminal with a processor.
Client 102 may initiate a remote session with server 104 by sending a request for remote access and credentials (e.g., login name and password) to server 104. If server 104 accepts the credentials from client 102, then server 104 may establish a remote session, which allows a user at client 102 to access applications and data at server 104. During the remote session, server 104 sends display data to client 102 over network 106, which may include display data of a desktop and/or one or more applications running on server 104. The desktop may include, for example, icons corresponding to different applications that can be launched on server 104. The display data allows client 102 to locally display the desktop and/or applications running on server 104.
During the remote session, client 102 may send user commands (e.g., inputted via a mouse or keyboard at client 102) to server 104 over network 106. Server 104 may process the user commands from client 102 similar to user commands received from an input device that is local to server 104. For example, if the user commands include mouse movements, then server 104 may move a pointer on the desktop running on server 104 accordingly. When the display data of the desktop and/or application changes in response to the user commands, server 104 sends the updated display data to client 102. Client 102 locally displays the updated display data so that the user at client 102 can view changes at server 104 in response to the user commands Together, these aspects allow the user at client 102 to locally view and input commands to the desktop and/or application that is running remotely on server 104. From the perspective of the client side, the desktop running on server 104 may represent a virtual desktop environment.
Windows I/O uses a layered architecture where device drivers are on a device stack. In a basic model, the top of the stack is the file system. Next is the volume manager, followed by the disk driver. At the bottom of the device stack are the port and miniport drivers. When an I/O request reaches the file system, it takes the block number of the file and translates it to an offset in the volume. The volume manager then translates the volume offset to a block number on the disk and passes the request to the disk driver. When the request reaches the disk driver it will create a Command Descriptor Block (CDB) that will be sent to the SCSI device. The disk driver imbeds the CDB into a structure called the SCSI_REQUEST_BLOCK (SRB). This SRB is sent to the port driver as part of the I/O request packet (IRP).
The port driver does most of the request processing including providing timing services for requests, enforcing queue depth (making sure that a device does not get more requests that it can handle), and building scatter gather arrays for data buffers. The port driver interfaces with a driver called the miniport. The miniport driver is designed by the hardware manufacturer to work with a specific adapter and is responsible for taking requests from the port driver and sending them to the target logical unit number (LUN). The port driver calls the HwStorStartlo( ) function to send requests to the miniport, and the miniport will send the requests to the LUN. When the request is complete, the miniport will call StorPortNotification( ) with the NotificationType parameter value set to RequestComplete, along with a pointer to the completed SRB.
When a request is sent to the miniport, the port driver will put the request in a pending queue. When the request is completed, it is removed from this queue. While requests are in the pending queue they are timed. There is one timer per logical unit and it is initialized to −1. When the first request is sent to the miniport the timer is set to the timeout value in the SRB.
The timer is decremented once per second. When a request completes, the timer is refreshed with the timeout value of the head request in the pending queue. So, as long as requests complete the timer will never go to zero. If the timer does go to zero, it means the device has stopped responding. In response, the port driver logs an error and takes corrective action by trying to reset the unit. When the unit is reset, all outstanding requests are completed with an error and they are retried. When the pending queue empties, the timer is set to −1 which is its initial value.
FIG. 2 is a block diagram of a local device virtualization system 200 which can implement this type of functionality when a USB mass storage device is redirected from a client 102 to a server 104 over a remote session. As shown, while client 102 has established a remote session with server 104, a USB mass storage device 240 is connected to client 102. In accordance with embodiments of the present invention, client 102 can be configured to redirect device 240 over the remote session so that the device is accessible on server 104. Proxy 210 on client 102 and agent 250 on server 104 can be configured to establish and maintain the remote session to enable this redirection.
FIG. 2 provides a general overview of the primary components that can be employed to redirect mass storage device 240 at the disk level. This technique can be referred to as disk level redirection and is distinguished from general USB redirection in that the redirection occurs at the disk level rather than at the USB device level. In particular, client 102 can include a disk driver stack 220 that includes a disk driver 220a, a USB storage driver 220b, and a USB hub driver 220c. As is known in the art, USB storage driver 220b and USB hub driver 220c can implement the USB protocol to enable communication with device 240 as a USB mass storage device. Disk driver 220a, which in some embodiments may be an instance of the disk.sys process, can function to service read/write requests and to abstract the underlying USB storage and hub drivers 220b, 220c. 
On the server side, a corresponding disk driver 282, which may be another instance of the disk.sys process, may sit below a file system stack 280 to receive and convert file system requests to disk requests (e.g., by creating a CDB and embedding it in an SRB) and to pass these disk requests (e.g., IRPs and associated SRBs) to a virtual disk enumerator 260 at the bottom of the device stack. It is noted that a volume manager is not shown in this figure for simplicity. Virtual disk enumerator 260 functions to virtualize mass storage device 240 on server 104 (as represented by virtual mass storage device 290). This virtualization is accomplished by routing the disk requests to agent 250 which will forward them over the remote session to proxy 210, down through disk driver stack 220, and to mass storage device 240 where they can be fulfilled. Corresponding responses can then be routed in a reverse direction towards virtual disk enumerator 260 and up through disk driver 282, file system stack 280, and ultimately to an application 270 that originated the request.
Virtual disk enumerator 260 can implement the port driver and miniport driver functionality described above. In particular, virtual disk enumerator 260 can implement the timer functionality for determining when an SRB has timed out, and, when a timeout occurs, can implement functionality to retry the outstanding requests.
FIG. 3 is a block diagram of local device virtualization system 200 when a device 340, which is not a mass storage device, is redirected to server 104. Regardless of the type of device that is redirected, the same general process is implemented. However, as shown in FIG. 3, when the redirected device 340 is not a mass storage device, the device is redirected at the USB level rather than at the disk level. Accordingly, in FIG. 3, client 102 includes a bus driver 330 (which would also be present in FIG. 2) and stub driver 320. Stub driver 320's primary function is to route the USB protocol data between device 340 and virtual bus driver 360. A device stack 380 that may include a number of drivers 382a-382n is layered on top of the virtual bus driver 360. These drivers 382a-382n perform the necessary functionality to allow operating system 170 and/or application 270 to access device 340 as a virtual device 390. For example, drivers 382a-382n can include any USB drivers or device specific drivers.
For purposes of the present invention, the important distinction between FIG. 2 and FIG. 3 is that, when a USB mass storage device is redirected, virtual disk enumerator 260, which includes port driver and miniport driver functionality, will be executed on server 104, whereas, when other types of USB devices are redirected (or at least USB devices that do not implement the SCSI standard), there will not be a SCSI component on server 104 that implements SCSI error checking and handling.
Whenever a device is redirected over a remote session, proxy 210 and agent 250 employ a transport layer connection to communicate. The transport layer connection may typically be established using either the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP). The primary distinction between these two protocols is that TCP provides reliability mechanisms while UDP does not. These reliability mechanisms include error checking, ordered delivery, and error recovery among others.
When TCP is used as the transport layer protocol, the implementation of the reliability mechanisms add substantial overhead thereby increasing the amount of time to deliver a packet over the connection. To address such issues, UDP may be employed as the transport layer protocol while implementing reliability mechanisms at the application level (e.g., by implementing Reliable UDP). In many cases, implementing the reliability mechanisms at the application level (e.g., within proxy 210 and agent 250) in conjunction with UDP can improve performance beyond what is attainable with TCP. However, there are still many situations where the reliability mechanisms will not be implemented optimally at the application layer thereby degrading the performance of the connection below that of TCP.